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ABSTRACT 

Aspect-Oriented Programming is making quantified programmatic 
assertions over programs that otherwise are not annotated to re- 
ceive these assertions. Varieties of AOP systems are characterized 
by which quantified assertions they allow, what they permit in the 
actions of the assertions (including how the actions interact with 
the base code), and what mechanisms they use to achieve the 
overall effect. Here, we argue that all quantification is over dy- 
namic events, and describe our preliminary work in developing a 
system that maps dynamic events to transformations over source 
code. We discuss possible applications of this system, particularly 
with respect to debugging concurrent systems. 

Categories and Subject Descriptors 

D.3.3 [Programming Languages]: Language Constructs and Fea- 
tures - aspects. D.3.2 [Programming Languages] Language Clas- 
sifications - aspect-oriented programming. D.2.3 [Software Engi- 
neering] Coding Tools and Techniques. D.2.5 [Testing and De- 
bugging] Debugging aids. 

General Terms 

Languages. 

Keywords 

Quantification, events, dynamic events, debugging, program 
transformation, model checking. 

1. INTRODUCTION 

Elsewhere, we have argued that the programmatic essence of As- 
pect-Oriented Programming is making quantified programmatic 
assertions over programs that otherwise are not annotated to re- 
ceive these assertions [10,12]. That is, in an AOP system, one 
wants to be able to say things of the form, “In this program, when 
the following happens, execute the following behavior,” without 
having to go around marking the places where the desired behav- 
ior is to happen. Varieties of AOP systems are characterized by 
which quantified assertions they allow, what they permit in the 
actions of the assertions (including how the actions interact with 
the base code), and what mechanisms they use to achieve the 
overall effect. In this paper, we describe our preliminary work in 
developing a system that takes the notion of AOP as quantifica- 
tion to its logical extreme. Our goal is to develop a system where 
behavior can be attached to any event during program execution. 
We describe the planned implementation of this system and dis- 
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cuss possible applications of this technology, particularly with 
respect to debugging and validating concurrent systems. 

2. EVENTS 

Quantification implies matching a predicate about a program. 
Such a predicate must be over some domain. In the quantifica- 
tion/implicit invocation papers, we distinguished between static 
and dynamic quantification. 

Static quantification worked over the structure of the program. 
That is, with static quantification, one could reference the pro- 
gramming language structures in a system. Examples of such 
structures include reference to program variables, calls to subpro- 
grams, loops, and conditional tests. 

Many common AOP implementation techniques can be under- 
stood in terms of quantified program manipulation on the static 
structure of a program. For example, wrapping (e.g., as seen in 
Composition Filters [1], OIF [11], or AspectJ [19,20]) is effec- 
tively embedding particular function bodies in more complex 
behavior. AspectJ and OIF also provide a call-side wrapping, 
which can be understood as surrounding the calling site with the 
additional behavior. An operation such as asserting that class A’s 
use of x is the same as class B's use of y in Hyper/J [22] can be 
realized by substituting a reference to a common generated vari- 
able for x in the text of A, and y in B. 

Dynamic quantification, as described in those papers, speaks to 
matching against events that happen in the course of program 
execution. An example of dynamic quantification is the jumping- 
aspect problem [2], where a method behaves differently depend- 
ing upon whether or not it has been called from within (in the 
calling-stack sense) a specified routine. Other examples of inter- 
esting dynamic events include the stack exceeding a particular 
size, the fifth unsuccessful call to the login routine with a different 
password, a change in the number of references to an object, a 
confluence of variable values (e.g., when x + y > z), the blocking 
of a thread on a synchronization lock, or even a change in the 
executing thread. The cflow operator in AspectJ is a dynamic 
quantification predicate. 

We are coming to the belief that all events are dynamic. Static 
quantification should be understood as just the subspecies of 
events that can be simply inferred, on a one-to-one basis, from the 
structures of a program. Static quantification is attractive for its 
straightforward AOP implementation, lower complexity, and in- 
dependence of programming environment implementation, but 
unless one starts processing the program comments, there’s little 



Table 1: Events and event loci 


Event 

Accessing the value of a variable or field 

Modifying the value of a variable or field 

Invoking a subprogram 

Cycling through a loop 

Branching on a conditional 

Initializing an instance 

Throwing an exception 

Catching an exception 

Waiting on a lock 

Resuming after a lock wait 

Testing a predicate on several fields 

Changing a value on the path to another 

Swapping the running thread 

Being below on the stack 

Freeing storage 

Throwing an error 


Syntactic locus 

References to that variable 

Assignments to that variable 

Subprogram calls 

Loop statements 

The conditional statement 

The constructors for that object 

Throw statements 

Catch statements 

Wait and synchronize statements 

Other's notify and end of synchronizations 

Every modification of any of those fields 

Control and data flow analysis over statements (slices) 

Not reliably accessible, but atomization may be possible 
Subprogram calls 

Not reliably accessible, but can try using built-in primitives 
Not reliably accessible; could happen anywhere 


in the static structure of a program that isn’t marked by its dy- 
namic execution. 

If the abstract syntax tree is the domain of static quantification, 
what is the domain of dynamic quantification? Considering the 
examples in this section, it really has to be events that change the 
state (both data state and “program counter”) of the base lan- 
guage’s abstract interpreter. However, defining anything in terms 
of the abstract interpreter is problematic. First, as was illustrated 
in Smith's work on 3-Lisp [5], programming languages are not 
defined in terms of their abstract interpreters. The same language 
can be implemented with many different interpreters. The set of 
events generated by one implementation of a language may not 
correspond to the events generated by another. For example, a 
run-time environment that manages its own threads is not at all 
the same as one that relies on the underlying operating system for 
thread management. Neither is the same as one that takes advan- 
tage of the multiple processors of a real multi-processor machine. 
Second, compilers have traditionally been allowed to optimize — 
rearrange programs while preserving their input-output semantics. 
An optimizing compiler may rearrange or elide an “obvious” se- 
quence of expected events. And finally, the data state of the ab- 
stract interpreter (including, as it does, all of memory) can be a 
grand and awkward thing to manipulate. 

3. A LANGUAGE OF EVENTS 

We view these limitations as bumps in the road, rather than barri- 
ers. While we may not be able to capture everything that goes on 
in a particular interpretive environment, we can get close enough 
for most practical purposes. The strategy we adopt is to argue that 
most dynamic events, while not necessarily local to a particular 
spot in the source code, are nevertheless tied to places in the 
source code. Table 1 illustrates some primitive events and their 
associated code loci. 


Users are likely to want to express more than just primitive 
events. The language of events will also want to describe relation- 
ships among events, such as that one event occurred before an- 
other, that a set of events match some particular predicate, that an 
event occurred within a particular timeframe, or that no event 
matching a particular predicate occurred. This suggests that the 
event language will need (1) abstract temporal relationships, such 
as “before” and “after,” (2) abstract temporal quantifiers, such as 
“always” and “never”, (3) concrete temporal relationships refer- 
ring to clock time, (4) cardinality relationships on the number 
times some event has occurred, and (5) aggregation relationships 
for describing sets of events. 

4. SYSTEM ARCHITECTURE 

We envision a mechanism where a description of a set of event- 
action pairs, along with a program, would be presented to a com- 
piler. Each event action pair would include a sentence describing 
the interesting event in the event language and an action to be 
executed when that event is realized. Said actions would be pro- 
grams, and would be parameterized with respect to the elements 
of the matching events. Examples of such assertions are: 

■ On every call to method foo in a class that implements the 
interface B, replace the second parameter of the call to foo 
with the result of applying method/to that parameter. 

■ Whenever the value of x+y in any object of class A ever ex- 
ceeds 5, print a message to the log and reset x to 0. 

■ If a call to method foo occurs within (some level down on 
the stack) method baz but without an intervening call to 
method mumble , omit the call to method gorp in the body of 
foo. 





These examples are in natural language. Of course, any actual 
system will employ something formal. 

Clearly, a sufficiently "meta” interpretation mechanism would 
give us access to many interesting events in the interpreter, ena- 
bling a more direct implementation of these ideas. It has often 
been observed that meta-interpretative and reflective systems can 
be used to build AOP systems [29]. However, meta-interpreters 
have traditionally exhibited poor performance. We are looking for 
implementation strategies where the cost of event recognition is 
only paid when event recognition is used. This suggests a com- 
piler that would transform programs on the basis of event-action 
assertions. Such a compiler would work with an extended abstract 
syntax tree representation of a program. It would map each predi- 
cate of the event language into the program locations that could 
affect the semantics of that event. Such a mapping requires not 
only abstract syntax tree generation (parsing) and symbol resolu- 
tion, but also developing primitives with respect to the control and 
data flow of the program, determining the visibility and lifetimes 
of symbols, and analyzing the atomicity of actions with respect to 
multiple threads. 

Java compiles into an intermediate form (Java byte codes). In 
dealing with Java, there is also the choice as to whether to process 
with respect to the source code or the byte code. Each has its ad- 
vantages and disadvantages. Byte codes are more real: many of 
the issues of interest (actual access to variables, even the power 
consumption of instructions) are revealed precisely at the byte 
code level. Working with byte codes allows one to modify classes 
for which one hasn’t the source code, including the Java language 
packages themselves. (JOIE [3] and Jmangler [21] are examples 
of an AOP systems that perform transformations at the byte code 
level.) On the other hand, source code is more naturally under- 
standable, allows writing transformations at the human level, and 
eliminates the need for understanding the JVM and the actions of 
the compiler. (De Voider’ s Prolog-based meta-programming sys- 
tem is an example of source-level transformation for AOP [6,7].) 
We find the complexity arguments appealing. Thus, our imple- 
mentation plan is to work at the source code level. 

5. EXAMPLES 

Event quantification is a general framework for supporting aspect 
oriented programming. It can be used for functionality enhance- 
ment, where a program is extended with aspects that add new 
functionality. For example, a program could be made more reli- 
able by transforming its database update events to also send mes- 
sages to a backup log. Although functionality extension is a gen- 
eral goal for AOP, we instead discuss some examples within the 
area of program verification. (In some cases, we expect to be able 


to extend program behavior for functionality insurance: recover- 
ing from some classes of program failure.) 

In previous work, we studied various program verification tech- 
niques for analyzing the correctness of programs. Our work can be 
classified into two categories: program monitoring [17] and pro- 
gram scheduling [16,27], The latter is often called model check- 
ing. 

5.1 Monitoring 

Specification-based monitoring consists of monitoring the exe- 
cution of a program, represented by a sequence of events, by vali- 
dating the events against a requirements specification. The speci- 
fication is written in some formal language, typically a temporal 
logic [24]. For example, a typical requirement is, “Whenever 
TEMP becomes 100 then within 3 seconds ALARM becomes 
true.” A typical requirement specification has many such asser- 
tions. We want to be able to run the program and monitor that 
specification assertions hold throughout the event trace. The Java 
PathExplorer system [17] implements this kind of capability. It 
uses the byte-code engineering tool Jtrek [18] to instrument Java 
byte code to emit events to an observer, which contains a data 
structure representing the formulae to be checked. Every event 
emitted from the running program causes a modification of the 
data structure. A warning is raised when a specification is vio- 
lated. We plan to experiment using event quantification at the 
source code level instead of at the byte code level. The events to 
be caught are obviously those implicitly referred to in the for- 
mula — in the above example, updates to the variables TEMP and 
ALARM. That is, whenever one of these variables is updated, an 
event consisting of the variable name, the value, and a timestamp 
can be emitted to the observer. (The evaluation of the temporal 
formula can even be performed as part of the quantification action 
instead of in a separate observer, if real-time performance is not 
an issue.) Operating on the source code level simplifies creating 
the instrumentation, as one can work in a high-level language, not 
byte code. The commercial-available Temporal Rover system 
performs specification-based monitoring, but does not do auto- 
mated code instrumentation [8], 

Algorithm-based monitoring, like specification-based moni- 
toring, watches the execution of a program emitting events. Rather 
than matching against user-defined specifications, algorithm- 
based monitoring uses certain general algorithms for detecting 
particular kinds of error conditions. Examples are algorithms for 
detection of deadlock and data race potentials in concurrent pro- 
grams. These algorithms are interesting since the actual deadlocks 
or data races do not have to occur in an execution trace in order to 
be identified as a potential problem. An arbitrary execution trace 
will normally suffice to identify problems. For example, a cyclic 
relationship between the locks in a program (thread T1 takes lock 
A and then B. while thread T2 takes B and then A) is a potential 
deadlock. A similar algorithm exists for data races [25]. These 
algorithms have been implemented in PathExplorer using byte 
code engineering, and we anticipate trying them out using event 
quantification. 

5.2 Scheduling 

Thread scheduling consists of influencing a program’s schedul- 
ing in order to explore more thread interleavings than would oth- 
erwise be achieved with normal testing techniques. As an exam- 
ple, the above mentioned deadlock situation can be explicitly 




demonstrated by scheduling the threads such that T1 takes A, and 
then T2 immediately takes B. Such a schedule might never be 
seen during normal test of the program. Thread scheduling can be 
achieved by introducing a centralized scheduler and forcing all 
threads to communicate with that scheduler when shared data 
structures (such as locks) are accessed. The scheduler then decides 
which thread to run, while at the same time keeping track of its 
scheduling choices. This information can then be used to direct 
the program to explore new interleavings. We have earlier devel- 
oped the Java PathFinder system [16, 27] for performing such 
scheduling analysis using model checking. In order to avoid ex- 
ploring the reachable subtree below a given program state several 
times, states are stored in cache, and search is aborted when a 
state has been visited before. Using quantification, we plan to 
experiment with state-less model checking [15, 24] where a pro- 
gram’s different interleavings are explored, but without storing 
states. An example of program modification to detect 
synchronization faults is ConTest [8], 

6. RELATED WORK 

De Voider and his co-workers [6,7] have argued for doing AOP 
by program transformation, using a Prolog-based system working 
on the text of Java programs. We want to extend those ideas to 
program semantics, combining both the textual locus of dynamic 
events and transformations requiring complex analysis of the 
source code. 

At the 1998 ECOOP AOP workshop, Fradet and Siidholt [13] 
argued that certain classes of aspects could be expressed as static 
program transformations. They expanded this argument at the 
1999 ECOOP AOP workshop to one of checking for robustness — 
non-localized, dynamic properties of a system's state [14]. Col- 
combet and Fradet realized an implementation of these ideas in 

[4], applying both syntactic and semantic transformations to en- 
force desired properties on programs. In that system, the user can 
specify a desired property of a program as a regular expression on 
syntactically identified points in the program, and the program is 
transformed into one that raises an exception when the property is 
violated. Other transformational systems include, Ku a notational 
attempt at formalizing transformation [27], and Schonger et al’s 
proposal to express abstract syntax trees in XML and use XML 
transformation tools for tree manipulation [26]. 

Nelson et al. identify three concern-level foundational composi- 
tion operators: correspondence, behavioral semantics and bind- 
ing [22]. Correspondence involves identifying names in different 
entities that are “the same” — for data items, things that should 
share storage; for functions, functional fragments that need to be 
assembled into a whole. Behavioral semantics describe how the 
functional fragments are assembled. Binding is the usual issue of 
the statics and dynamics of system construction and change. They 
discuss alternative formal techniques for establishing properties of 
composed systems within this basis. 

Walker and Murphy argue for events as appropriate “join points” 
for AOP, and that the events exposed by AspectJ are inade- 
quate [32]. 

7. CONCLUDING REMARKS 

In this paper, we've examined the idea of implementing AOP 
systems as programs transformed by quantified responses to dy- 
namic events. Two comments about the place of such a system in 
the order of things are worth making: 


■ We’ve been talking about implementation environments, 
not software engineering. An underlying implementation 
does not imply anything about the “right” organization of 
"separate concerns” to present to a user. In particular, we 
have been completely agnostic about the appropriate struc- 
ture for the actions of action-event pairs. It may be the case 
that unqualified use of an event language with raw action 
code snippets is a software engineering wonder, but we 
doubt it. 

■ An environment that can map from quantified dynamic 
events to modified code would be an excellent environment 
for experimenting with and building systems for AOP. In 
some sense, these ideas can be viewed as a domain-specific 
language for developing aspect-oriented languages. 
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